The overall capacities of broadband satellites are increasing exponentially, and such capacity increases present unique challenges in the associated ground system and network designs. The goal of the system designers, system operators, and service providers is to support and provide efficient, robust, reliable and flexible services, in a shared bandwidth network environment, utilizing such high capacity satellite systems. For example, in a network with multiple remote nodes (e.g., remote terminals) using shared bandwidth to attempt to send data into the network, quality of service (QoS) is required on every link of the network in each direction. Further, an appropriate bandwidth allocation mechanism is required to achieve the QoS requirements for interactive traffic and to optimize channel utilization (e.g., to increase bandwidth availability, while decreasing bandwidth waste). In the satellite network, for example, supporting delay sensitive data traffic over the return or inroute link (the link from the remote terminal back to the gateway) presents significant challenges with regard to network resource management. Such challenges are due to various factors, including difficulty in balancing latency performance and channel efficiency (e.g., efficient bandwidth utilization). Delay or latency sensitive traffic of varying input rates (e.g., regular or secured web browsing—such as hypertext transfer protocol (HTTP) and secure HTTP (HTTPS)) is typically classified as an interactive class, which can be transmitted using periodic and high priority backlog-based bandwidth allocations. Data traffic through terrestrial backhaul is also latency sensitive and demanding on bandwidth.
Further, certain conditions may be present in such a system, such as: (1) the incidence of interactive applications that are more latency sensitive (e.g., voice over Internet Protocol (VoIP) and web-browsing, which reflect a class of applications that require bursts of small bandwidth allocations when actively transmitting data; (2) the interactive applications generally require minimum or no delay in transmitting data, thus requiring bandwidth to be effectively available instantaneously; (3) the inability for interactive applications to rely on bandwidth allocated in response to explicit bandwidth requests as packets arrive for transmission; (4) the difficulty in identifying bandwidth demands of interactive applications in advance, because of the inherent randomness of the user operations in such interactive applications; and (5) the inability to provide continuous dedicated bandwidth allocation to remote nodes.
In the presence of such conditions, it becomes a challenge to satisfy bandwidth requirements criteria for latency sensitive applications. For example, such criteria may include utilization of request-based bandwidth allocation algorithms or approaches to allocate bandwidth, while meeting the delay requirements for interactive traffic, the provision of continuous dedicated bandwidth at some predefined rate that satisfies such delay requirements (e.g., such would be inefficient in terms of channel utilization), and addressing dynamic changes in application bandwidth demands, and continuing to make bandwidth allocations in a manner that minimizes transmission delay and increases channel utilization. Moreover, such criteria become even more demanding in a shared bandwidth access network with long round trip propagation delay (e.g., a satellite network). For example, in a satellite network, supporting delay sensitive data traffic in the return-link (inroute) direction presents enhanced challenges in network resource management, based, as one example, on enhanced difficulties in balancing latency performance and channel utilization (e.g., a difficult balance presents itself when trying to allocate bandwidth that predicts the arrival of delay sensitive traffic, without significant underutilization of network resources).
Current bandwidth on demand (BOD) systems or algorithms either allocate bandwidth on an as needed basis in attempts to achieve optimal channel or bandwidth utilization efficiency, but thereby sacrifice efficiency in satisfying the requirements of latency sensitive applications, or allocate a pre-determined rate of bandwidth in attempts to achieve efficiency in satisfying the requirements of latency sensitive applications, but thereby sacrifice optimal channel or bandwidth utilization efficiency. Other current methods apply a hybrid approach of these foregoing two methods, but fail to achieve an efficient and satisfactory predictive balance (e.g., with a simple algorithm for providing additional predictive bandwidth to improve latency, while releasing unneeded bandwidth to improve channel efficiency and bandwidth utilization). Further, some current methods may apply a predictive periodic bandwidth approach, but fail to address all of the bandwidth requirements criteria for latency sensitive applications (e.g., fail to optimize latency and bandwidth utilization on both the individual link of a terminal as well as system-wide). For example, in order to serve latency sensitive traffic at the return channel (inroute) in current systems, in anticipation of the arrival of delay sensitive traffic to active terminals, a gateway (GW) assigns a constant periodic bandwidth to such terminals above their respective demands. While this may serve to reduce traffic latency, however, it wastes bandwidth (e.g., when a terminal is currently receiving an active periodic bandwidth, but does not have a respective level of data (or any data) to send. Further, such an approach may also limit near term throughput when a terminal exhibits a sudden burst of delay sensitive traffic that exceeds the constant periodic assignment.
One example of the application of a periodic bandwidth allocation is with respect to HTTPS applications. HTTPS traffic requires a certain amount of periodic bandwidth to maintain reasonable latency. For example, in some instances HTTPS traffic may require a periodic bandwidth of 20 kbps to 32 kbps, assisted by backlog-based bandwidth allocations, to provide reasonably satisfactory latency performance. More specifically, on an inroute with QPSK rate 4/5 modulation, 9 slots of periodic bandwidth allocation every 2 frames would provide approximately 19.2 kbps, and 15 slots every 2 frames would provide approximately 32 kbps. Accordingly, ideally, a particular applications HTTPS traffic requirements should be able to be satisfied by providing such a constant periodic rate. In reality, however, it is difficult to identify the particular applications/terminals running HTTPS, as the data packets are multiplexed at the link layer. Typically, therefore, current approaches allocate periodic bandwidth to all active terminals so as not to degrade the performance of those terminals running secured HTTP transactions. The periodic bandwidth is then released when the network observes no activity from the terminal for a preconfigured amount of time. As the number of subscribers grows, however, the number of active terminals, which would force a reduction of the periodic bandwidth allocations to the active terminals, and thus results in a degradation of HTTPS performance in those terminals actually running HTTPS applications. For example, if the periodic bandwidth allocation is reduced to 6 slots every 4 frames or 3 slots every 2 frames (at QPSK rate 4/5) only a 6.4 kbps rate is provided, which would be unsatisfactory for the terminals running HTTPS applications. Also, for the terminals not running HTTPS applications, not all the allocated periodic bandwidth is utilized, which results in a low inefficient utilization of the inroute bandwidth. Other applications of periodic bandwidth allocation include web browsing, interactive gaming, interactive streaming, and adaptive constant bit rate (CBR) services.
What is needed, therefore, is a system and method to address the challenges providing an appropriate bandwidth allocation mechanism in a shared bandwidth network environment, which satisfies QoS requirements for interactive traffic, while optimizing channel/bandwidth utilization.